UNCLASSIFIED 


NAVAL  POSTGRADUATE  SCHOOL  MONTEREY  CA  F/6  9/2 

A  MODEL  FOR  ESTIMATING  TACTICAL  SOFTWARE  MAINTENANCE  REQUlREMEN— * ETC (U) 
JUN  62  M  H  MERRING 


AD  All 821 1 


NAVAL  POSTGRADUATE  SCHOOL 

Monterey,  California 


A  MODEL  FOR  ESTIMATING 
TACTICAL  SOFTWARE  MAINTENANCE 
REQUIREMENTS 


William  K.  Merring,  III 


--**  -  to, 


V  • 


June  1982 


AL'3  1  6  1982 


Thesis  Advisors : 


D.  C.  Boger 
R.  Modes 


Approved  for  public  release:  distribution  unlimited 


82  08  16  I?' 


53g2E !  'unAjMii-iAiiimgriz 


REPORT  DOCUMENTATION  PAGE 


READ  INSTRUCTIONS 

■crone  connmNo  fork 


*▼*106  mum*** 


«.  TiTUf  tm*  Mmiiu 

A  MODEL  FOR  ESTIMATING  TACTICAL  SOFTWARE 
MAINTENANCE  REQUIREMENTS 


7.  *uTNOM<'<> 


»  TV**  OF  *«*0*T  •  *CMO0  COVCMCO 

Master's  Thesis 

2 


«.  FCNFOMMMO  0*0.  ***0*T  KUMHa 


William  H.  Merring,  III 


rn  '•'l,I.W.,TVT*TTT\7^’^TT^,T  RrtT-' 


Naval  Postgraduate  School 
Monterey,  California  93940 


I  I  COMTHOkUMO  OFFICE  MAM*  *N0  AODNCtt 

Naval  Postgraduate  School 
Monterey,  California  93940 


*11*1/  MMIN  *■  C— Wilt**  OfftMi 


It.  «**0*T  OAT* 

June  1982 


I*.  MUM***  OF  **OCt 

51 


MCUMITV  CL**».  (ml  rnm  ■ 

Unclassified 


i*.  otirmsunoM  it  atimsmt  /•/  «*••  «a*i) 


Approved  for  public  release:  distribution  unlimited 


OtSTMSuTtOM  IT  AT  (MINT  (ml  «*•  attlml  mtmrmrn  m  Sim*  M.  II  rnHmml  mm  Kmmrt) 


00  I  ,  1473  CWTIOtl  OF  1  MOV  ••  I*  ossoust* 


S/N 


•CeuMTV  CLARIFICATION  of  TMIt  **•■  I 


ira-m ! nan "i  '.iiiimmj  r.'irr 


20 .  (.continued) 

during  the  development  phase  to  reduce  maintenance  costs  over  the  life- 
cycle  of  the  system.  It  also  presents  a  model  that  uses  the  known  con¬ 
figuration  of  the  program  to  estimate  the  maintenance  personnel  require¬ 
ments  for  that  system.  These  requirements  will  be  estimated  from  the 
beginning  of  the  maintenance  phase  to  its  completion.  The  model  utilizes 
the  technique  of  measuring  the  characteristics  of  the  software  to  obtain 
the  estimation. 
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ABSTRACT 


Recent  studies  have  pointed  to  the  increasing  harden 
that  is  software  saintenance.  The  maintenance  of  tactical 
systems  software  will  dee  and  resources  that  exceed  those 
expended  daring  the  development  phase  as  their  nuabers  and 
time-  in- service  increase.  This  increased  demand  for 
resources  requires  aore  effective  management  of  the  aainte¬ 
nance  phase  and  development  of  the  software  with  aaintenance 
in  aind. 

This  thesis  presents  those  items  that  should  be  consid¬ 
ered  and  utilized  during  the  development  phase  to  reduce 
maintenance  costs  over  the  life-cycle  of  the  systea.  It 
also  presents  a  aodel  that  uses  the  known  configuration  of 
the  prograa  to  estimate  the  aaintenance  personnel  require¬ 
ments  for  that  systea.  These  requirements  will  be  estimated 
froa  the  beginning  of  the  aaintenance  phase  to  its  comple¬ 
tion.  The  model  utilizes  the  technique  of  measuring  the 
characteristics  of  the  software  to  obtain  the  estimation. 
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i.  laiBSMsiiaa 


A.  CONTEXT  OF  THE  STODY  AND  BACKGROUND 

The  saint enance  of  software  that  has  been  acquired  and 
sade  operational  by  the  government  is  a  growing  concern. 
The  nuaber  of  tactical  cosputer  prograas  in  service  and 
those  under  developaent  will  increase  the  future  requireaent 
for  aore  effective  and  detailed  planning  of  all  resources  in 
the  software  aaintenance  area.  Not  only  the  nuaber  of  these 
systeas,  but  also  the  length  of  tine  that  these  systems 
remain  operational  will  add  to  the  requirement  for  more 
effective  maintenance  manageaent.  This  management  will  be 
especially  demanding  with  regards  to  personnel  requirements 
since  this  will  potentially  be  the  most  expensive  and  diffi¬ 
cult  single  resource  to  manage. 

The  Harine  Corps  Tactical  Systems  Support  Activity 
(BCTSSA)  has  the  Harine  Corps  responsibility  for  aaintenance 
of  the  software  of  tactical  systeas  [Ref.  1].  The  objective 
of  this  research  is  to  present  the  current  ideas  in  software 
engineering  and  aaintenance.  This  study  was  completed  with 
HCTSS A* s  function  in  Bind,  but  this  should  not  be  construed 
as  Uniting  the  tenets  outlined  in  this  paper  as  being 
limited  to  HCTSSA.  They  should  be  applicable  in  varying 
degrees  to  all  software  projects. 

It  is  important  at  this  point  to  realize  that  good  main¬ 
tainability  begins  very  early  in  the  software  developaent 
process  and  can  only  be  planned  from  the  beginning  of  the 
system  life-cycle.  Attempts  to  improve  maintainability  late 
in  the  project  are  potentially  hazardous  to  the  integrity  of 
the  software  and  extremely  can  be  expensive.  The  inclina¬ 
tion  on  the  part  of  the  developers  to  reduce  near-term  costs 
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at  the  expense  of  eaintain  ability  alaost  ensures  that  the 
effort  expended  later  in  the  life-cycle  will  far  exceed  any 
iaaediate  advantage* 

Host  of  the  literature  available  on  software  aaintenance 
and  its  related  aspects  falls  into  the  area  of  general 
purpose  coaputing.  Little  of  the  current  inforaation  avai¬ 
lable  specifically  addresses  tactical  coaputer  software, 
while  this  initially  appeared  to  restrict  sources  of  infor¬ 
aation,  it  becaae  apparent  that,  even  though  there  are  soae 
definite  differences  between  tactical  and  general  purpose 
coaputing,  they  are  less  iaportant  than  the  siailarities. 
The  particularly  deaanding  parts  of  tactical  systeas  are  the 
real-tiae  requireaents  or  scheduling  constraints,  and  the 
"critical"  or  "life- and -death"  nature  of  their  decisions. 
In  the  bulk  of  general  purpose  software  these  features  are 
either  not  present  or  not  present  to  the  sane  degree. 
Cffef*  2].  The  software  will  to  a  great  extent  be  siailar  in 
coaposition  even  if  the  requireaents  differ.  Additionally, 
nany  of  the  processors  that  the  tactical  systeas  are  based 
on  were  originally  designed  for  a  coaaercial  or  general 
purpose  systeas. 

Software  aaintenance,  for  the  purposes  of  this  paper, 
will  be  defined  as  those  actions  which  are  taken  to  repair 
or  beneficially  alter  the  software  in  a  systea  that  leaves 
the  aajority  of  the  instructions  in  the  prograa  unaltered 
and  the  designed  function  of  the  systea  intact.  Software 
aaintenance  has  been  divided  into  two  types,  corrective 
aaintenance  and  adaptive  aaintenance  [Bef.  3]. 

Corrective  aaintenance  is  that  aaintenance  which  is 
required  to  repair  errors  or  ia prove  the  functioning  of  the 
software  without  altering  its  priaary  functions.  The  latter 
part  of  this  type  of  aaintenance  would  concern  itself  with 
essentially  perfecting  the  prograas  or  Baking  thea  aore 
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aachine  efficient.  The  repair  portion  would  consist  of 
fixing  errors.  These  errors  can  range  in  degree  froa  an 
error  that  results  in  total  failure  of  the  system  to  an 
error  that  is  bothersoae  but  has  no  effect  on  perforaance 
(Ref.  4].  The  second  type  of  aaintenance  is  that  of 
enhanceaent  or  adaptive  aaintenance.  This  occurs  when  a 
ainor  change  in  the  function  of  software  is  desired.  This 
change  can  improve  the  systea  by  increasing  its  capabilities 
or  changing  its  operation  to  the  fora  that  the  user  desires 
at  soae  tiae  after  the  systea  has  been  Bade  operational'. 
The  changes  aade  should  leave  aost  of  the  systea' s  software 
as  it  was. 

Software  aaintainability  is  that  degree  to  which  the 
software  can  be  changed  or  corrected.  It  is  the  degree  of 
ease  the  aaintainer  has  in  understanding  the  software  and 
then  applying  the  proper  corrective  action  or  integrating 
the  desired  enhanceaent.  Software  reliability  is  the  extent 
to  which  the  prograa  perforas  its  designed  functions  accu¬ 
rately  and  in  a  tiaely  aanner.  These  two  concepts  will  be 
related  to  each  other  throughout  the  life  of  the  software. 

B.  FORHAT  OF  THE  THESIS 

This  paper  has  been  broken  into  two  aain  sections.  The 
first  section  will  describe  those  aethods  that  should  be 
used  early  in  the  life-cycle  of  the  software.  The  objective 
of  this  section  is  to  present  those  ideas  that  should  have 
their  greatest  effect  on  reducing  the  total  life-cycle  cost 
of  the  software  with  eaphasis  on  reducing  the  costs  of  the 
aaintenance  phase.  It  is  iaportant  to  stress  that  extra 
tiae  or  aoney  spent  early  in  the  project  can  reduce  costs 
later  in  the  life-cycle  of  the  software  at  an  extreaely 
favorable  rate. 
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The  second  section  of  the  paper  will  deal  with 
presenting  a  proposed  aodel  for  the  predicition  of  the 
personnel  required  for  aaintenance  of  a  system's  software 
once  HCTSSA  assuees  fall  responsibility  for  this  function, 
in  important  feature  to  note  in  this  aodel  is  that  it  is 
based  on  the  known  and  quantifiable  parts  of  the  software. 
The  progress  have  already  been  written  and  thus  HCTSSA  will 
know  what  they  consist  of.  This  fact  alone  should  aid  the 
predictive  capabilities  of  the  aodel. 


II.  DESIGNING  SOFTWARE  FOB  MAINTAINABILITY 


A.  SOFTSABE  LIFE-CYCLE 

The  software  life-cycle  can  be  divided  into  six  distinct 
areas.  These  are  Requirements  Analysis,  Specification, 
Design,  Coding,  Testing,  and  Operations  and  Naintenance  (see 
Figure  2.1)  [Bef.  5].  Each  of  these  areas  can  be  further 
broken  into  sub-areas  and  often  overlap.  Only  those  itees 
that  are  pertinent  to  saint enance  will  be  developed. 

B.  REQUIREMENTS  ANALYSIS 

During  the  requirenents  analysis  the  type  of  systen  and 
its  capabilities  are  identified.  This  process  takes  place 
between  the  user  and  the  developer.  Although  in  the  past 
this  phase  has  been  considered  less  important,  it  is  both 
critical  to  successful  maintenance  and  difficult.  It  is 
critical  because  one  must  ensure  that  the  user's  require¬ 
ments  are  met  and  it  is  difficult  because  this  phase  has  not 
lent  itself  to  the  kind  of  structuring  that  allows  a  cook¬ 
book  or  step-by-step  approach.  The  user  and  developer 
during  this  phase  attempt  to  determine  the  user's  needs,  a 
step  which  is  often  difficult  to  accomplish  with  the  tech¬ 
nical  tools  available  to  conduct  the  project  [Bef.  6  j. 

Itees  that  are  important  to  consider  during  this  phase 
which  improve  subsequent  maintainability  include,  first, 
identifying  the  maintenance  group  (in  this  case  NCTSSA)  and 
including  them  in  the  review  of  the  system  requirements 
[Ref.  7].  The  purpose  of  this  is  twofold,  first,  to  deter¬ 
mine  the  maintenance  facility's  capability  to  support 
maintenance  and  to  allow  the  maintenance  managers  to  begin 
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Requirements  Analysts 


FIGURE  2.1  Software  life  Cycle  Phases. 


Source:  McClure.  C«rn«  L.,  lf*PV)<"fl  t"<l'|»|,‘  n.  «inn«nn.  etui  Maintenance 
v«n  Noeirtnd  Relnnold  CBoMny,  Figure  3.1.  0.  39. 


planning  for  the  aainte nance  phase  of  the  project  in  rela¬ 
tion  to  the  other  systeas  currently  operational.  Second,  it 
is  at  this  tine  that  thought  should  be  given  to  developing 
schedules  of  priorities,  enhancements,  and  resource  alloca¬ 
tion.  The  enhanceaent  portion  would  be  extreaely  difficult 
to  define  precisely,  but  planning  for  it  needs  to  be 
conducted  in  soae  fora  as  experience  has  shown  that  this 
accounts  for,  on  the  average,  forty-two  percent  of  the 
aaintenance  effort  [Bef.  8].  This  early  identification  of 
enhanceaent s  should  afford  the  aaintenance  facility  enough 
lead  tiae  to  begin  considering  its  support  requireaents. 
The  previous  experience  of  the  facility  in  dealing  with 
enhanceaents  should  also  allow  it  to  sake  an  estiaate  of  the 
enhanceaent  rate.  The  developaent  of  enhanceaent  estiaation 
should  include  data  gathered  froa  both  the  vendor  and  the 
facility.  This  requires  the  establishaent  of  a  database 
that  deals  with  these  areas  and  is  readily  available  to  the 
aanagers  of  the  software  aaintenance  facility. 

C.  SPECIFICATION  PHASE 

It  is  during  the  specification  phase  that  the  functions 
of  the  systea  are  defined.  This  has  to  be  done  with  the 
user  to  ensure  that  his  reguireaents  will  be  set.  Failure 
to  accoaplish  this  will  result  in  costly  corrections  either 
before  acceptance  when  discrepancies  arise  during  testing  or 
later  when  adaptive  aaintenance  has  to  be  done  to  bring  the 
systea  in  line  with  the  user's  needs.  Figure  2.2,  the 
inforaation  for  which  was  obtained  froa  the  Software 
Maintenance  Guidebook  by  B.  L.  Glass  and  B.  A.  Hoiseux, 
shows  how  the  cost  per  error  increases  as  the  life  cycle 
progresses. 

This  phase  should  be  conducted  between  the  user  and  the 
developer  to  ensure  that  both  understand  the  potentials  of 
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the  systea.  The  user  so  that  unreasonable  deaands  or  expec¬ 
tations  are  not  aade  and  the  developer  to  ensure  he  under¬ 
stands  what  the  user  requires  and  explain  vhat  is  within  the 
capabilities  of  the  current  technology. 

The  specifications  give  a  concise  description  of  the 
systea*s  functions  to  both  the  user  and  the  developer 
tBef«  9 ].  The  coapleteness  and  correctness  of  these  speci¬ 
fications  will  govern  the  entire  project.  Good  specifica¬ 
tions  will  afford  aanageaent  better  estiaates  of  the 
aagnitude  of  the  project  for  scheduling  purposes. 
Conversely ,  poor  specifications  will  result  in  software  that 
cannot  be  expected  to  perfora  adequately  or  even  be  useful 
for  the  increased  costs  that  it  will  create.  It  is  during 
this  phase  that  structured  progressing  should  be  incorpo¬ 
rated  into  the  project  to  specify  the  structure  of  the  soft¬ 
ware  for  the  design  phase. 

During  this  phase  the  aaintainer  should  be  included  in 
review  of  the  specifications  and  he  should  evaluate  the 
iapact  on  current  systeas  [  Ref.  10].  The  latter  allows  the 
saint enance  facililty  to  refine  the  planning  for  aaintenance 
begun  during  the  require aents  analysis  phase  and  the  foraer 
allows  the  aaintainer  to  provide  insight  as  to  what  sections 
of  the  prograa  can  be  provided  through  reused  code.  It  is 
at  this  tiae  the  identification  of  those  areas  that  could  be 
iapleaented  through  the  utilization  of  reused  code  should 
begin. 

D.  DESIGN  PH &S 2 

The  design  phase  is  when  the  structure  of  the  software 
is  actually  delineated.  The  designer  develops  in  detail  a 
structured  hierarchy  of  aodules.  This  phase  is  critical  as 
studies  have  identified  that  alaost  sixty-four  percent  of 
the  software's  errors  have  arisen  froa  poor  design 
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[Bef.  11].  i  well-structu  red  design  will  either  elieinate 
errors  or  facilitate  detection  of  design  errors  early  in  the 
life-cycle  of  the  systea  when  they  are  least  expensive  to 
fix.  This  is  also  the  phase  daring  which  the  eost  widely 
accepted  Methods  of  ensuring  aaintainability  are  instituted. 

Structured  design  is  the  first  of  these  aethods. 
Structured  design  consists  of  following  an  established  set 
of  procedures  for  accoeplishing  the  design  phase.  It  estab¬ 
lishes  the  fraaework  for  the  software  and,  when  properly 
coapleted,  facilitates  aaintenance  The  structure  or  fraae¬ 
work  of  the  aodules  should  be  hierarchial  with  control 
flowing  froa  top  to  bottoa  in  a  logical  Banner  with  no  level 
calling  on  a  higher  level.  The  top  level  should  be  the 
highest  level  of  control  logic  present  [Bef.  12]. 

Part  of  this  structure  is  the  design  aodules,  which  are 
those  aodules  that  are  constructed  during  the  design  phase. 
They  have  been  deterained  to  iaprove  aaintainability  by 
alaost  eighty-nine  percent  of  their  users  [Bef.  13].  The 
key  aspect  of  the  aodules  is  that  they  should  perfora  a 
single  function.  This  reduces  their  coaplexity  and  allows 
far  both  easier  error  checking  and  error  correction.  The 
aspect  of  a  single  function  is  iaportant  to  aaintenance  as 
it  aakes  the  nodule  easier  for  the  aaintainer  to  understand 
what  the  aodule  is  doing.  The  capacity  of  the  systea  to  use 
previously  coded  aodules  is  increased  through  this  aethod. 
lddit ionally,  the  flexiblity  of  the  systea  is  increased 
through  the  plug-in  capabilities  inherent  in  nodular  design. 

During  this  phase  it  is  again  iaportant  for  the  devel¬ 
oper  and  the  prospective  aaintainer  to  naintain  close 
contact.  The  aaintainer  is  able  to  provide  insight  as  to 
what  and  how  the  current  systeas  are  perforaing  and  espe¬ 
cially  to  provide  inforaation  on  what  functional  aodules 
have  already  been  coded  and  are  available  froa  previous 
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projects.  The  object  here  is  to  redoes  the  total  effort  and 
possibly  eliainate  any  pitfalls  that  have  been  experienced 
in  previous  designs. 

Docuaentation  of  the  prograa  increases  in  iaportance  as 
the  developaent  of  the  systea  progresses.  The  developer 
should  ensure  that  all  steps  of  the  process  are  explained 
fully.  ill  parts  of  the  hierarchy  and  nodules  should  be 
explained  coapletely  to  ensure  adequate  understanding  of 
both  their  functions  and  aethods  of  iapleaentation.  This 
will  considerably  ease  the  naintainer's  burden  when  he  has 
to  correct  errors  or  enhance  the  systea  auch  later  in  the 
life  of  the  systea  when  those  who  developed  the  systea  are 
not  available  for  explanations  as  to  why  and  how.  The 
aaintenance  personnel  can  provide  valuable  input  to  the 
docuaentation  design  by  providing  inforaation  on  those  types 
that  have  proved  especially  helpful  and  easy  to  use. 

E.  COOING 

This  phase  is  possibly  the  best  understood  phase  in  the 
entire  life-cycle.  However,  there  are  iteas  that  need  to  be 
particularly  adhered  to  if  aaintain ability  is  to  be 
obtained.  The  first  of  these  is  widely  recognized  as  aiding 
both  developaent  and  aaintenance.  It  is  the  use  of  a  high 
order  language.  The  greatest  contribution  of  a  high  order 
language  is  that  it  adds  readibility  to  the  prograa,  thus 
increasing  the  understanding  of  the  code.  Another  technique 
that  will  facilitate  understanding  of  the  code  is  the  use  of 
structured  prograaaing.  This  is  the  grouping  of  siailar 
nodules  and  the  use  of  such  techniques  as  indentation  of 
inside  a  prograa  to  increase  readability. 

Sensed  code  has  excellent  potential  to  reduce  the  life 
cycle  costs  of  software.  It  can  do  this  through  reducing 
coding  and  testing  of  nodules,  and  consolidation  of 


naintenance  through  reduction  of  the  total  nuaber  of  unique 
aodules  that  need  to  be  aaintained.  It  has  been  applied  in 
United  situations  vith  significant  iaprovenents  in 
productivity  and  reductions  in  developnent  and  naintenance 
costs  (Bef.  ie].  The  naintenance  facility  would  be  required 
to  naintain  a  library  of  current  nodules  that  are  available 
for  use  and  in  operation.  It  would  also  naintain  the  data 
on  those  aodules  in  terns  of  error  rates,  systen  locations 
and  other  iaportant  inforaation. 

It  is  during  this  phase  that  reused  code  is  inserted 
into  the  prograa  where  it  was  identified  as  being  suitable. 
Through  the  reuse  of  code,  aot  only  the  coding  tine  but  also 
the  testing  effort  is  reduced.  The  reused  code  has  been 
tested  and  iapleaented  in  other  systens  and  has  been  proven. 
There  should  be  nany  areas  in  each  new  prograa  that  provide 
the  opportunity  for  the  reuse  of  code.  &  reduction  in 
required  naintenance  should  occur  as  one  nodule  is  repaired, 
the  change  can  be  applied  to  all  systens  using  that  nodule 
(Ref.  IS].  The  priaary  advantage  in  terns  of  naintenance  is 
the  reduction  in  the  probabilty  of  errors  being  generated  by 
that  nodule. 

Upon  conpletion  of  the  coding  and  the  checking  of  the 
nodule  by  the  prograa ner,  that  nodule  should  be  passed  on  to 
be  checked  by  another  individual.  This  checker  should  use  a 
checklist  that  identifies  the  conaon  errors  that  arise  in 
prograas  (lef.  16].  The  use  of  the  checklist  will  iaprove 
the  productivity  of  the  inspection  process  greatly.  in 
exaaple  of  an  inspection  checklist  can  be  found  in  T.  Gilb's 
book  on  SStSmg  BllSlSg  P-  59. 

1  technique  that  shows  auch  pronise  in  increasing  both 
the  aaintainability  and  reliability  of  software  is  the  use 
of  dual  code.  The  dual  code  technique  would  be  iapleaented 
during  this  phase  of  the  life-cycle  and  consists  of 


utilizing  the  structure  developed  during  the  design  phase  to 
independently  construct  tvo  sets  of  code.  While  it  would 
appear  to  increase  costs  by  a  factor  of  tvo,  it  has  in  its 
lisited  application  increased  costs  over  the  life-cycle  fros 
five  to  ten  percent  in  cases  where  no  future  benefits  have 
been  obtained.  In  aost  cases,  however,  a  net  cost  savings 
of  up  to  fifteen  percent  or  a  substantial  increase  in  the 
quality  of  the  code  produced  has  been  realized  (Bef.  17]. 

The  advantages  of  dual  code  can  be  sanifold.  The  first, 
and  aost  iaportant  in  terns  of  tactical  systens,  is  the 
increased  quality  of  the  software  produced.  The  reason  for 
this  is  that  the  two  sets  of  code  will  check  each  other. 
The  results  they  produce  can  be  checked  to  deter nine  if 
there  are  differences  between  then  and  thus  possible  errors. 
Therefore  a  check  on  the  quality  of  the  coding  is  provided. 
This  technique  would  have  one  prograa  essentially  do  the 
work  of  the  desk  tester,  thus  autonating  this  step  in  the 
process  £Be€.  18 J.  This  autonation  of  the  desk  testing 
process  should  increase  the  dependability  of  the  checking 
that  is  conducted.  Dual  code  is  also  used  in  conjunction 
with  the  Debugging  technique,  which  will  be  explained  later. 

P.  TESTING  PHASE 

The  testing  phase  can  be  broken  into  three  parts:  unit 
level,  integration,  and  systes  testing.  Unit  level  testing 
is  done  for  each  nodule  to  determine  if  it  functions  prop¬ 
erly.  Integration  testing  is  coapleted  next  and  is  done  in 
either  a  top-down  or  botton-up  fashion.  It  ensures  that  the 
nodules  will  work  properly  in  the  progran  environnent.  The 
systen  test  is  coapleted  next  and  is  done  to  ensure  that  the 
systea  aeets  the  specification  it  was  designed  for. 

The  aaintainer  should  be  involved  in  this  entire  phase 
to  give  advice  on  the  test  nethodology.  He  has  current 
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information  that  concerns  systems  that  are  on-line  and  is 
able  to  highlight  likely  areas  for  extra  attention  daring 
testing. 

Host  iaportant  daring  the  testing  phase  is  the  documen- 
tation  of  the  testing.  This  documentation  should  provide 
information  on  the  error  rate  of  each  nodule,  the  type  of 
error,  and  difficulties  with  the  overall  system.  Also 
included  should  be  data  on  the  manpower  and  resources 
required  on  the  project  to  date,  broken  down  by  modules  if 
possible.  Table  I  contains  an  example  of  the  data  that 
should  be  included  on  the  program's  test  history.  This 
information  is  iaportant  to  the  aaintainer  as  it  will  give 
him  some  idea  as  to  possible  trouble  spots  in  the  software 
and  an  overall  idea  as  to  the  difficulty  he  will  experience 
in  maintaining  the  entire  program.  A  system  that  is  diffi¬ 
cult  to  maintain  early  in  its  life  tine  will  continue  to  be 
difficult  throughout  its  entire  life  and  needs  to  be  identi¬ 
fied  as  such  as  early  as  possible. 

G.  HOVE BE  IT  IHTO  THE  HAINT  ENAHCE  PHASE 

During  a  study  conducted  by  Lientz  and  Swanson,  it  was 
determined  that  the  best  organization  for  conducting  mainte¬ 
nance  is  one  that  performs  that  function  solely.  This 
facility  should  be  separate  from  that  of  development.  They 
gave  as  possible  reasons,  increased  efficiency  and  greater 
control  of  efforts  and  reduced  costs  that  arise  from  this 
specialization  [Bef.  19).  Additional  benefits  can  occur 
through  the  possible  career  enhancement  of  programmers  who 
become  involved  with  maintenance. 

A  tradeoff  of  a  separate  maintenance  function  as 
compared  to  one  integrated  with  development  is  that  the 
*■  productivity  of  the  aaintainers  declines  when  fever  of  the 

original  developers  are  involved  in  maintenance  [Bef.  20]. 
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r ABLE  I 


Program  Test  History. 


TJSrt  "Ted€”!irs^crfy - 

- JToIBef  ”on55tiI5?Ua  rBTS’Sf  W - 

Average  Nuaber  of  Unit  Tests  Executed  per  Nodule 
Number  of  Errors  Discovered  daring  Testing 
Average  Nuaber  of  Errors  Discovered  in  a  Module (UAEH) 
Total  Nuaber  of  Statements  Hoiified  to  Correct  Errors 
List  of  Nodules  in  which  the  Nuaber  of  Errors  Dis¬ 
covered  Exceeds  OAEH 
Types  of  Errors  Discovered 
-Hardware  Failure 

-Software  Reaction  to  Hardware  Failure 

-Coding  Error 

-Design  Error 

-Specification  Error 

-Logic  Error* 

-Computational  Error* 

-Data  Error* 

Average  Length  of  Tiae  to  Discover  and  Correct  an 
Error 


Int5ffaBIoff-TS5B~msf5f7 - 

- !TCiggf~gr-TgBe5gm5fi~TggfS~Bggginrg3 - 

Nuaber  of  Errors  Discovered  during  Integration 
Testing 

Average  Nuaber  of  Errors  Discovered  in  a  Nodule (I  A  EM) 
List  of  Nodules  in  which  the  Number  of  Errors  Dis¬ 
covered  Exceeds  IAEN 

Total  Nuaber  of  Statements  Hoiified  to  Correct  Errors 
Total  Nuaber  of  Nodules  Nodified  to  Correct  Errors 
Types  of  Errors  Discovered 

Average  Length  of  Time  to  Discover  and  to  Correct  an 


■  S  J  5BW  '  TlcgepWlS  eT”T5f  r’HrSBor  ? - 

- refi3gg~ffipsygEgi~Ti;gg?ggiregr~Tggfg-E*ggrrgg-~ 

Nuaber  of  Errors  Discovered  during  Systea (Acceptance) 
Testing 

Ayerage  Nuaber  of  Errors  Discovered  per  Nodule  (SABN) 

List  of  Nodules  Nodi  flea  to  Correct  Errors 

Types  of  Errors  Discovered 

Average  Length  of  Time  to  Correct  an  Error 


*Error  type  added  by  author  of  this  thesis 

*a  L,,  Nanagini  Software  Development 
Nostr  an“ffeIInolt  CoHpany,  Tsoi  el.?. 


Source:  HcClure,  C 
qna  maintenance,  v 


ari 

an 
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This  can  be  partially  compensated  through  the  use  of  a 
"maintenance  escort"  [Ref.  21].  This  escort  will  take  part 
in  the  development  of  the  software  and,  when  the  systee*s 
responsiblity  for  aaintenance  is  transferred,  he  goes  along 
with  it  to  provide  the  needed  experience  to  reduce  the 
initial  aaintenance  effort  and  improve  the  learning  of  the 
aaint miners. 

Since  prograaaers  will  not  be  constantly  in  deaand  on  a 
specific  project,  the  organization  should  be  constructed 
such  that  departaents  with  experienced  personnel  are  organ¬ 
ized  around  a  specific  functional  area  of  software,  such  as 
input,  arithaetic,  output,  signal  processing  or  data  display 
types  of  software.  This  would  allow  the  prograaaers  to 
become  experts  on  specific  areas.  The  departaents  would 
consist  of  functional  areas  that  are  coaaon  to  all  projects 
and  allow  prograaaers  to  becoae  experienced  with  that  type 
of  function.  The  departaents  would  send  the  required  people 
to  the  requesting  projects  on  an  as-requested  basis.  To 
ensure  faailiarity  with  the  project,  specific  prograaaers 
would  be  allocated  to  certain  projects  on  a  consistent 
basis.  The  objective  of  this  systea  is  to  obtain  greater 
utilizaton  of  experienced  prograaaers,  the  alternative  being 
their  complete  devotion  to  a  specific  project  with  the 
resulting  under  utilization  of  their  skills  and  abilities. 

The  management  of  software  aaintenance  is  unique  in  many 
respects  and  requires  attention  to  soae  special  areas. 
First,  it  should  be  realized  that  about  twenty  percent  of 
the  tiae  the  aaintainer  will  actually  be  eaployed  in  correc¬ 
tive  aaintenance  (>•£-  2?].  The  remainder  will  be  eaployed 
in  conducting  adaptive  aaintenance.  This  is  iaportant,  in 
that,  while  it  nay  be  difficult  to  fix  bugs  in  progress,  it 
is  aore  difficult  and  costly  to  add  enhanceaents  to  the 
software  such  that  it  Beets  the  same  stringent  requireaents 


of  the  original  product.  The  maintenance  of  software  is  a 
repeating  cycle  that  requires  the  saae  steps,  although  on  a 
saaller  scale,  that  were  conducted  during  the  development 
phase.  Figure  2.3  shows  the  recommended  cycle  for  including 
enhancements. 

It  is  important  that  the  addition  of  an  enhancement  take 
place  in  much  the  saae  manner  as  the  development  process  to 
ensure  that  the  quality  of  the  software  is  maintained.  The 
maintainer  needs  to  document  changes,  employ  structured 
programming  and  modularization  in  much  the  same  way. 
Failure  to  do  so  will  throughly  destroy  a  good  program  and 
even  shorten  its  possible  useful  life.  Critical  to 
conducting  adaptive  maintenance  is  the  determination  of 
whether  it  is  worth  the  effort  to  add  the  enhancement.  An 
evaluation  should  be  conducted  on  each  proposed  enhancement, 
to  determine  if  the  potential  benefits  exceed  the  possible 
long  term  costs.  This  process  when  used  on  small  scale 
enhancements  may  prove  infeasible,  but  it  should  definitely 
be  required  for  all  enhancements  that  have  the  potential  for 
consuming  large  amounts  of  resources. 

Beused  code  will  show  an  additional  benefit  in  the  area 
of  changes.  That  is,  if  a  change  is  required  in  one  module 
that  change  can  possibly  be  instituted  in  all  other 
instances  of  that  module.  The  correction  of  an  error  would 
then  only  have  to  be  detected  and  corrected  once,  rather 
than  waiting  for  the  remainder  of  similar  modules  to  err  and 
require  correction. 

Essential  to  the  aaintenance  function  is  the  accumula¬ 
tion  of  data  on  the  various  types  of  projects  that  are  being 
maintained  by  the  activity.  These  data  need  to  be  tabulated 
from  the  beginning  of  the  project  to  its  end  and  require 
completeness.  That  is  the  data  need  to  include  information 
on  the  functions  and  nodules  of  the  program.  For  instance. 
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Figure  2.3.  Structuring  the  maintenance  process 
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they  should  include  the  error  rate,  what  types  of  errors, 
when  they  were  found,  and  especially  how  long  it  took  to 
find  and  repair  thea.  These  data  will  enable  aanageaent  to 
gain  better  insight  into  the  aaintenance  process  and  allow 
thea  to  fora  better  estiaa tes  on  personnel  requirements  to 
conduct  this  function.  Models  can  prove  useful  in  this 
respect,  but  will  prove  even  aore  useful  when  there  are  data 
available  to  deteraine  their  validity.  The  data  accumulated 
will  provide  auch  irforaation  on  the  aaintenance  process  and 
its  usefulness  will  cross  over  into  other  projects  because 
of  a  large  degree  of  coaaon  properties  in  software. 

H.  SOMMART 

One  of  the  ideas  that  should  have  beccae  apparent  froa 
the  preceding  discussion  is  that  aaintenance,  quality  and 
reliability  are  intrinsically  related.  Designing  for  reli¬ 
ability  and  quality,  while  not  necessarily  increasing  main¬ 
tainability,  will  reduce  the  maintenance  costs,  if  for  no 
other  reason  than  the  elimination  of  errors.  These  three 
are  aore  deeply  related  because  the  use  of  structured 
programming  and  modularity  not  only  increases  maintain¬ 
ability  by  decreasing  complexity  but  also  increases  quality 
and  reliablity  for  the  sane  reason.  The  human  programmer  is 
able  to  comprehend  only  a  limited  amount  of  a  program. 
These  techniques  allow  him  to  understand  what  he  is  working 
on  and  in  what  context,  reducing  the  probabilty  of  errors 
early  in  the  life  of  the  system.  That  is  the  key  to  all  of 
aaintenance,  making  the  software  as  easily  understandable  as 
is  possible,  thus  increasing  the  capability  of  the  aain- 
tainer  to  find  and  repair  or  add  the  desired  changes.  It  is 
possible  to  develop  reliable  software  that  is  relatively 
complex  without  making  it  maintainable;  it  has  probably  been 
done  aore  than  once.  It  is  easier  to  accomplish  and 
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certainly  less  expensive  to  conduct  the  software  developaent 
process  with  the  objectives  of  reliablity,  quality,  and 
aaintainability  when  these  tenets  are  adhered  to  than  it 
would  be  if  they  are  not  considered. 

The  three  potential  aethods  to  achieve  the  above  objec¬ 
tives  are  dual  code, reused  code  and  bebugging.  The  latter 
will  be  explicitly  treated  in  the  following  chapter.  Dual 
code  can  increase  reliability  of  code  by  providing  a  ready 
check  on  that  code  to  ensure  that  it  is  error  reduced. 
Reused  code  should  reduce  costs  through  reduction  in  testing 
of  aodules  and  coding  required.  It  should  additionally 
improve  reliability  through  the  use  of  previously  tested  and 
proven  code.  Bebugging  will  allow  the  manager  to  estimate 
the  error  rate  of  the  code  and  its  aaintainability  through 
some  simple  testing  procedures.  This  method  is  important  in 
that  it  provides  a  measure  of  the  quality  and  aaintain¬ 
ability  of  the  program,  thereby  improving  the  planning  for 
maintenance. 


27 


III.  SOGG ESTEP  MODEL  FOB  ESTIMATING  PERSONNEL  REQUIREMENTS 

PORING  MAINTENANCE 


A.  I  NT ROD OCT ION 

Prior  to  entering  the  aaintenance  phase,  it  is  extreaely 
iaportant  to  have  an  estiaate  of  the  resources  required  to 
conduct  it.  An  especially  iaportant  part  of  these  resources 
is  the  personnel  requireaen ts.  The  people  who  aaintain  the 
systeas  software  will  prove  to  be  the  largest  single  expense 
of  the  aaintenance  portion  of  the  life-cycle.  There  have 
been  a  nuaber  of  aodels  developed  to  estiaate  the  develop- 
aent  costs  of  software  and  a  few  have  atteapted  to  extend 
their  predictions  to  include  the  aaintenance  phase 
[Bef.  23],  [Bef.  24],  [Hef.  25],  [Bef.  26].  The  enphasis  of 
these  aodels  is  to  utilize  the  functions,  size,  and  applica¬ 
tions  of  the  software  to  estiaate  its  life-cycle  costs  prior 
to  the  initiation  of  developaent  and  coding.  This  is  essen¬ 
tially  the  aacro  approach  to  looking  at  the  overall  func¬ 
tions  of  the  systea  and  using  thea  to  estiaate  resource 
require  aents. 

Bhile  in  aany  cases  any  aodel  or  estiaating  technique  is 
better  than  no  foraalized  technique  at  all,  the  construction 
of  a  aodel  should  be  based  on  a  thorough  understanding  of 
the  coaponents  of  the  systea.  This  could  be  considered  the 
aicro  approach.  The  aodel  presented  here  is  one  approach  to 
understanding  that  portion  of  the  life-cycle  called  aainte- 
nance.  It  atteapts  to  explain  the  interactions  of  the 
coaponents  of  software  aaintenance  with  a  view  toward  pred¬ 
icting  the  resource  requireaents.  Fundaaental  to  the  aodel 
is  the  fact  that  the  developaent  phase  has  been  coapleted 
and  that  the  systea  is  in  use. 
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Therefore,  the  size,  functions,  and  applications  of  the 
prograe  are  veil  kncvn  and  can  be  utilized  in  the  estimation 
model.  This  approach  should  integrate  veil  vith  HCTSSi's 
role  as  a  aaintenance  facility  as  this  is  the  point  in  tine 
that  they  assume  responsibility  for  the  softvare  systea. 

The  presentation  of  the  aodel  covers  the  tvo  types  of 
aaintenance  that  vere  defined  in  Chapter  I,  corrective 
aaintenance  and  adaptive  aaintenance.  The  objective  of  the 
aodel  is  to  deteraine  the  anount  of  effort  required  to 
conduct  both  types  of  aaintenance. 

The  aajor  assumptions  made  in  this  aodel  are  that  the 
development  of  the  systea  has  been  completed  and  it  is 
currently  in  use.  The  aaintenance  facility  is  assuaing 
responsibility  for  the  softvare  and,  thus,  knovs  its 
content.  This  allovs  for  tore  accurate  use  of  an  estiaation 
aodel  based  on  an  in-depth  analysis  of  the  code  itself. 
Further  assumptions  are  that  the  systea  has  been  developed 
in  accordance  vith  the  guidelines  presented  earlier  in  this 
paper.  ihile  all  guidelines  aay  not  have  been  folloved  in 
every  instance,  the  aodel  is  presented  such  that  the  reader 
should  be  able  to  adjust  its  construction  to  suit  his  use. 

8.  DEVELOP HE NT  OP  BETBIC  TO  ESTIBATE  CORRECTIVE  HAI NTENANCE 
WORKLOAD 

1 .  Debugging 

"Bebugging"  is  a  tera  coined  by  T.  Gilb  and  is 
derived  froa  a  concept  developed  by  H.  Bills  that  introduces 
a  number  of  knovn  errors  into  a  program  to  calibrate  the 
error  location  process  (Ref.  27].  The  concept  is  that  of 
introducing  a  knovn  nuaber  of  errors  and  then  performing  a 
debug  exercise  on  the  prograa.  The  objective  is  to  compare 
the  seeded  nuaber  of  errors  detected  to  the  errors  that 
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occurred  naturally  in  the  prograa  and  then  use  these  figures 
to  estisate  the  total  nuaber  of  bugs  present  in  the  prograa. 
Conducting  this  test  over  a  specific  period  of  tine  will 
afford  a  aeasure  of  the  bug  detection  rate. 

6.  Schick  and  B.  Rolverton  in  their  article,  "in 
Analysis  of  Coapeting  Software  Reliability  Hodels”  suaaar- 
ized  the  work  of  H.  Hills  and  the  later  work  of  S.  Basin  and 
presented  a  foraula  that  can  be  utilized  in  calculating  an 
estiaate  of  the  aaxiaun  nuaber  of  errors  present  in  the 
software.  That  foraula  is: 
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where, 

H*  aaziaua  nuaber  of  errors, 

IHT*  integer  value  of  evaluated  expression, 

r=  nuaber  of  stateaents  in  the  test, 

k(1)»  nuaber  of  stateaents  in  test  in  which  indigenous 
errors  were  detected, 

k(2)»  nuaber  of  stateaents  in  test  in  which  seeded 
errors  were  detected, 

n{1)«  nuaber  of  stateaents  in  which  errors  were  intro¬ 
duced, 

H»  total  nuaber  of  aachine  executable  stateaents  in  the 
systea  [Ref.  28]. 

This  foraula  is  based  on  a  count  of  the  stateaents  with 
errors.  The  errors  are  seeded  randoaly  in  the  entire 
prograa  and  in  executable  instructions  only. 

2.  laoleaent ation  2l  Bagging 

The  iapleaent ation  of  bebugging  should  be  relatively 
siaple  and  straightfoward.  The  seeding  of  the  prograa  needs 
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to  be  dose  randomly.  This  can  be  done  manually  or  automati¬ 
cally  through  the  machine'  s  use  of  a  predetermined  algor¬ 
ithm.  The  error  type  to  be  introduced  should  be  considered 
at  this  point.  The  type  of  error  introduced  needs  to  repre¬ 
sent  the  proper  proportion  cf  that  arror  in  relation  to  the 
total  number  of  errors.  (Ref.  29].  The  type  of  bugs  or 
errors  considered  in  this  test  are  semantic.  The  categories 
of  semantic  bugs  are  computational,  logical,  and  data 
(Ref.  30].  The  syntactic  type  of  bug  is  not  considered  as 
it  should  be  detected  during  complilation  (Ref.  31]  and 
design  errors  are  generally  considered  too  difficult  to 
artificially  introduce.  The  best  method  for  obtaining  the 
proportion  of  error  types  is  to  refer  to  the  vendor  supplied 
information  on  this  project  and  to  data  that  has  been  accu¬ 
mulated  on  other  similar  projects.  The  errors  introduced 
should  reflect  this  proportion  in  order  to  obtain  a  repre¬ 
sentative  estimate.  Bhen  the  test  is  run  each  type  of  error 
should  be  calculated  separately  using  the  above  formula. 
This  is  essential  as  each  type  of  error  will  require  a 
different  degree  of  effort  to  repair. 

Two  methods  are  readily  apparent  for  detecting 
errors  after  the  program  has  been  seeded.  The  first  of 
these  methods  is  manual  detection  by  the  programmer  or 
programmers  who  will  be  involved  in  the  maintenance  of  the 
system.  It  is  important  that  those  involved  with  the 
maintenance  participate  in  the  test  to  achieve  calibration 
of  the  model  to  the  programmer's  capabilities  and  possibly 
eliminate  any  variance  that  could  arise  from  differences  in 
programmer  skill.  This  will  provide  additional  information 
on  how  long  it  takes  for  the  programmer  to  detect  and  then 
correct  the  errors.  The  test  should  consist  of  timing  how 
long  it  takes  for  the  programmer  to  locate  an  error  by  type. 
This  could  be  accomplished  by  maintaining  a  time-sequenced 


listing  of  when  each  error  was  found  by  type.  The  detection 
rate  could  then  be  established  for  each  error  type  by 
obtaining  the  average  nuaber  of  errors  detected  per  a 
specific  tiae,  in  this  case  a  aan-hour.  This  rate  is  valid 
if  the  systea  is  to  be  constantly  reviewed  for  errors  by 
these  individuals.  The  alternative  to  this  aethod  is  to 
develop  a  aodel  which  is  able  to  predict  an  error  rate  valid 
for  the  operating  cycle.  This  aodel  would  obtain  a  value 
that  would  show  the  rate  at  which  errors  appeared  during 
operation  of  the  systea  and  required  repair. 

The  second  aethod  of  obtaining  the  error  count  is 
through  the  use  of  the  dual  code  technique.  Dual  code 
provides  two  parallel  iaple aentations  of  the  design  specifi- 
cations,  in  either  the  saae  or  different  languages  and  has 
been  discussed  earlier  in  section  S  of  chapter  II.  In  the 
bebugging  context  the  seeded  or  artificial  errors  are  intro¬ 
duced  into  one  of  the  code  sets.  The  two  code  sets  are  run 
in  parallel  and  their  results  are  coapared  during  running 
for  discrepancies  [Ref.  32].  The  differences  in  the  results 
will  yield,  since  the  two  sets  of  code  were  coded  indepen¬ 
dently,  indicators  as  to  where  errors  lie  in  the  prograa. 
One  set  of  code  will,  in  effect,  check  the  other  through 
this  process.  The  code  set  with  the  introduced  errors  will 
be  used  to  obtain  the  error  estiaate.  This  aethod  will 
yield  only  an  estiaation  of  the  total  nuaber  of  errors  and 
an  error  rate  per  lines  of  code.  It  will  not  allow  one  to 
deteraine  the  aaintainabilt y  of  the  code  through  the  use  of 
prograaaers. 

Since  the  dual  code  aethod  will  yield  only  an  esti- 
aated  nuaber  of  errors,  the  two  aethods  of  annual  and  dual 
code  should  be  used  together.  The  reason  is  to  obtain  a 
check  on  the  nuaber  of  projected  errors,  and  because  only 
the  annual  aethod  can  provide  an  indicator  as  to  the  tiae 
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required  to  detect  and  correct  errors  by  a  specific 
prograeeer.  If  only  one  method  can  be  used  due  to  resource 
constraints,  the  nanual  aathcd  is  preferred  as  it  provides 
three  types  of  information,  that  of  error  rate,  detect¬ 
ability  of  the  errors,  and  the  aaintainability  of  the  code. 

Bebuqging  vas  selected  as  a  possible  aethod  for  the 
maintenance  facility  to  evaluate  the  software  for  planning 
purposes  for  a  number  of  reasons.  It  is  conducted  indepen¬ 
dently  of  the  vendor  and  allows  verification  of  his  data  and 
the  techniques  employed.  Ihile  discrepancies  between  esti¬ 
mates  are  sure  to  arise,  large  discrepancies  should  be 
suspect  and  should  subject  either  the  facility's  or  vendor's 
methods  to  re-evaluation.  The  bebugging  test  is  conducted 
under  the  conditions  and  with  the  people  that  will  be  preva¬ 
lent  during  the  maintenance  phase.  The  test  should  be  rela¬ 
tively  simple  to  structure  and  implement  by  the  facility. 
Additionally,  the  concepts  involved  are  easy  to  understand 
by  those  participating. 

There  are  some  distinct  disadvantages  to  bebugging 
that  should  be  discussed.  The  first  is  that  it  fails  to 
identify  the  degree  of  error.  The  degree  of  an  error  can 
fall  into  one  of  five  categories:  1)  error  which  prevents 
the  accomplishment  of  an  essential  function,  2)  error  which 
adversely  affects  the  accomplishment  of  an  essential  func¬ 
tion  degrading  performance,  3)  error  which  adversely  affects 
the  accomplishment  cf  an  essential  function  degrading 
performance,  but  has  a  work-around  solution,  4)  error  which 
is  merely  as  operator  inconvenience,  and  5)  all  other  errors 
(Bef.  33].  As  can  be  seen  from  the  above  definitions,  the 
degree  of  the  error  is  the  extent  to  which  the  system's 
functioning  is  affected  and  not  the  cause  of  the  error  or 
error  type.  The  degree  of  error  and  design  errors  do  not 
lend  themselves  to  detection  though  the  bebugging  technique 


due  to  their  conplexity.  Alternative  aethods  need  to  be 
developed  in  this  area. 

An  additional  trouble  area  becaae  apparent  during 
research  and  that  is  the  probleas  that  occur  when  repairing 
a  bug.  The  possibility  always  exists  £or  the  repair  '£ 
the  bug  to  introduce  additional  errors  through  unpredictable 
effects  on  other  aodules.  The  best  insurance  to  insulate 
against  these  effects  is  the  preservation  of  nodularity  and 
the  use  of  infornation-hiding  nodules  which  do  not  allow  the 
prograaner  to  aake  any  assuaptions  that  could  later  prove 
dangerous  to  the  prograa.  Additionally,  the  use  of  struc¬ 
tured  progressing  and  the  techniques  described  in  Chapter 
II,  section  C  should  work  to  reduce  the  design  errors  that 
nay  develop  later.  This  is  exeaplified  by  Figure  3. 1. 

The  use  of  be  bugging  will  produce  an  estinate  of  the 
error  detection  rate  that  can  be  used  for  planning  purposes, 
if  it  is  recognized  that  this  is  just  an  estinate  and  not 
what  will  occur.  The  bebugging  aethod  can  be  used 
periodically  to  evaluate  the  current  status  of  the  software 
at  various  points  along  the  aaintenance  path.  The  estiaates 
derived  therefroa  can  be  used  to  refine  or  revise  planning 
figures.  Further,  greater  confidence  in  an  estinate  can  be 
achieved  through  nore  testing,  although  at  additional  cost. 

3.  laiimiaa  si  sagasliia  flaUlaasasa  gat&lsaS 

The  corrective  aaintenance  workload  can  be  predicted 
using  the  nuaber  of  estiaated  errors  in  the  systea  and  the 
rate  of  error  detection  established  by  the  prograaaers 
during  the  bebugging  test  using  equation  <1>.  The  error 
detection  rate  as  well  as  the  nuaber  of  errors  should  be 
divided  into  the  three  types  of  seaantic  bugs  identified 
earlier.  The  resultant  foraula  should  estinate  the  aaount 
of  corrective  aaintenance  that  will  be  required  on  the 
systea. 
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Errors  Per  10,000  Lines  of  Code. 

Figure  3.1,  Software  maintenance  Improvements 
with  structured  programming. 


The  foraula  is: 


N  <C)  +  _N(1)_  +  _NJd) 
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where, 

CM*  total  corrective  a aintenance  required  in  nan-hours, 
N(i)  *  number  of  i  type  error  estimated 
(c*cosputational,  l*logical,  d*data)  using  equation  <1>,  and 
d(i)  *  the  detection  rate  in  errors  per  nan-hour  of  i 
type  error. 

C.  DEVELOPMENT  OP  HETBIC  TO  ESTIMATE  ADAPTIVE  MAINTENANCE 
LOAD 

Adaptive  aaintance,  as  previously  defined,  is  that 
naintenance  conducted  to  inprove  the  systen  by  increasing 
its  capabilites  or  change  its  operation  to  a  forn  that  the 
user  desires  after  the  systen  is  operational.  These  changes 
or  enchancenents  are  accoaplished  to  inprove  the  overall 
efficiency  of  the  systen,  add  new  features,  or  provide 
interfaces  with  other  systems  that  were  not  called  for  in 
the  original  design.  The  enhancenents,  in  nany  cases, 
should  not  substantially  alter  the  original  design  of  the 
prograa.  If  a  aajor  redesign  is  warranted,  the  systen 
should  be  returned  to  the  developnent  phase  to  ensure  that 
the  design  is  done  properly.  The  adaptive  naintenance 
discussed  here  will  cover  those  cases  where  nodules  nay  be 
changed  or  added,  but  the  structure  of  the  original  progran 
essentially  renains  intact. 

The  addition  of  enhancenents  should  be  conducted  along 
the  lines  of  the  original  developnent  process  to  ensure 
that,  while  the  systen  is  enhanced,  the  changes  are  inte¬ 
grated  into  the  systen  with  a  aininal  degrading  effect  on 
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performance.  An  understanding  of  the  systea  to  be  enhanced 
is  required.  This  understanding  is  governed  by  the  logical 
and  structural  coaplexities  of  the  software.  Adaptive 
aaintenance  involves  two  aajor  types  of  enhancements.  A 
portion  of  then  involves  alteration  and  a  snail  addition  of 
code  and  a  portion  requires  the  addition  of  a  new  nodule, 
rep  lace Bent  of  an  older  module  or  a  restructuring  of  the 
software's  structure.  The  degree  to  which  each  portion 
presents  itself  during  the  life  of  a  systea  is  as  yet  indet- 
erainate  and  will  require  in-depth  study.  Experience  can 
provide  some  indication  as  to  how  often  and  to  what  extent 
these  two  degrees  of  enhanceaent  are  nade. 

1.  isssi  flalgjgaflla  aet£ic  as  a  Measure  of  t&e 

In  order  that  a  aodification  nay  be  made,  the  indi¬ 
vidual  asking  the  change  needs  to  understand  the  systea.  The 
aaount  of  tine  he  takes  before  he  can  begin  useful  work  on 
the  systea  is  governed  by  the  coaplexity  of  that  systea.  The 
degree  of  software  coaplexity  is  inversely  related  to  the 
level  of  understanding.  The  sore  complex  the  software,  the 
less  well  understood  it  will  be  until  nore  effort  is 
expended  in  an  effort  to  ia prove  coaprehesion. 

Halstead's  development  of  programming  effort  essen¬ 
tially  realized  this.  Halstead's  effort  aetric  was  devel~ 
oped  to  analyze  the  effort  required  to  construct  a  program 
in  a  specific  language  fro  a  a  preconceived  algorithm.  Its 
application  in  aaintenance  for  using  it  to  rate  the 
coaplexity  of  the  software  should  prove  valid.  To  develop 
progressing  effort  Halstead  used  the  concepts  of  program 
level  and  voluae  [Ref.  34]. 

Program  level  refers  to  the  level  of  a  program's 
iapleaentation.  There  is  a  minimum  level  of  implementation 
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where  the  fewest  number  of  operands  and  operators  possible 
can  be  used  and  the  program  will  still  function  as  intended. 
This  most  elegant  of  implementations  is  never  realized  in 
fact  and  some  lower  program  level  is  achieved.  The  easiest 
language  to  use  would  have  a  program  level  of  one,  where  any 
procedure  desired  would  consist  of  merely  a  call  on  that 
procedure.  This  would  reguire  an  infinite  list  of  procedures 
and  is  not  realizable.  Implementations  of  programs  will 
fall  into  an  area  of  program  level  less  than  one.  Use  of 
this  greater  number  of  statements  and  the  consequent  expla¬ 
nation  results  in  greater  understanding  of  the  implementa¬ 
tion  for  the  person  less  familiar  with  the  system  The 
difficulty  of  the  comprehension  of  a  program  varies 
inversely  with  the  level  of  that  program  (  Ref .  35]. 

is  presented  by  Halstead,  the  program  level  is 
affected  by  the  operators  present.  The  larger  the  number  of 
operators  employed,  the  lower  the  level  of  implementation. 
The  minimum  number  of  operators  possible  is  two,  where  one 
would  consist  of  a  function  designator  and  the  other  an 
assignment  operator.  The  program  level  is  therefore  propor¬ 
tional  to  the  minimum  number  of  operators  possible  divided 
by  the  actual  number  of  unique  operators  [Ref*  36]. 

Operands  do  not  show  a  similar  minimum  over  all 
imple mentions*  In  cases  where  an  operand  name  is  repre¬ 
sented,  the  implementation  is  at  a  lower  level  than  was 
possible  if  the  operand  was  used  only  once.  The  program 
level  is  then  proportional  to  the  ratio  of  the  number  of 
unique  operands  to  the  total  operand  usage  [Ref.  37]* 
Combining  the  two  proportionalities  and  noting  that  the 
constant  of  proportionality  is  one,  as  this  is  the  maximum 
defined  value  of  program  level,  yields  the  program  level,  L, 
as 
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<3> 


where, 

n(1)  =  the  nuaber  of  unique  operators, 
n(2)  =  the  nuaber  of  unique  operands, 

N(2)  =  the  total  nuaber  of  operands  present  and  two  is 
considered  the  ainiaua  nuaber  of  operators  possible 
[Bef.  38]. 

Prograa  level  represents  a  aeaure  of  how  well  the  software 
has  been  iapleaented  in  relation  to  the  capabilities  of  the 
language  that  has  been  used.  The  better  the  implenentation 
the  closer  to  one  the  value  of  L  becoaes. 

Prograa  vcluae  recognizes  the  iaportance  of 
obtaining  a  aetric  for  the  size  of  a  algoritha  that  not  only 
aeasures  its  physical  length  but  also  the  nuaber  of  distinct 
operations  perforaed  in  the  prograa.  The  objective  is  to 
allow  application  to  a  wide  variety  of  languages.  Voluae  V 
has  been  defined  as: 

*  -  ILj-Lajm.  <4> 


where, 

H  is  equal  to  length  or  H1+N2,  the  total  nuaber  of 
operators  and  operands  utilized,  and 

n  is  the  vocabulary  of  unique  operators  and  operands  or 
n(1)+n(2)  (Bef.  39]. 

This  voluae  can  be  applied  to  any  prograaaing  language  and 
aeasures  the  size  of  the  prograa  in  the  language  coded.  It 
takes  into  account  the  capabilites  of  the  language  as 
presented  by  the  nuaber  of  unique  operators  and  operands  and 
its  size  as  represented  by  the  total  nuaber  of  operators  and 
operands.  Prograa  voluae  represents  an  overall  aeasure  of 
the  size  of  a  prograa  in  relation  to  that  prograa*  s  coe  pre¬ 
hen  sibility. 
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Halstead  uses  the 


To  obtain  the  effort  metric,  E, 
ratio  of  program  volume  to  program  level  [Ref.  40]. 

E  =  V/L  <5> 


From  this  equation  it  can  be  seen  that  as  the  program  volume 
increases,  the  effort  or  complexity  will  increase  and  that 
as  the  program  level  increases  the  effort  decreases  in  kind. 
Executing  the  necessary  substitutions  to  allow  for  calcula¬ 
tion  of  the  complexity  of  the  program  the  eguation  becomes: 


E 


n(1)  x  N  (2)  x 


ln”i~" 


<6> 


This  formula,  when  used  to  determine  the  complexity 
of  a  program  in  relation  to  a  programmer's  debugging  perfor¬ 
mance,  accounted  for  over  twice  as  much  variance  in  perfor¬ 
mance  as  a  metric  that  counted  solely  the  total  number  of 
program  statements  [Bef.  4  1],  The  resultant  value,  when 
applied  to  programs  on  board,  will  provide  an  estimate  of 
the  complexity  of  a  program,  thereby  refining  the  estimate 
of  the  quantity  of  resources  required  to  make  alterations  to 
the  software. 

Implicity  treated  in  the  above  formula  is  the  way  in 
which  modularity  affects  the  complexity  of  the  program.  The 
use  of  modules  such  as  functions,  subroutines  and  macros 
will  reduce  the  program  volume  through  their  inclusion. 
They  are  performed  multiple  times  during  execution  of  the 
program,  but  will  be  present  only  a  single  time  when  the 
software  is  reviewed  or  checked.  Through  their  single 
inclusion,  they  reduce  the  total  number  of  operators  and 
operands  present,  directly  reducing  the  program  volume  and 
increasing  its  comprehensibility.  Additionally,  as  Halstead 
indicated,  the  number  of  unique  operators  will  increase  with 
the  addition  of  subroutine  or  function  calls,  again  reducing 
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the  overall  complexity  of  the  system.  Interesting  to  note 
at  this  point  is  that  Halstead,  through  further  development, 
has  stated  that  E  will  vary  with  the  sguare  of  the  volume 
and  not  linearly  in  relation  to  the  program's  potential 
minimum  volume  (the  best  implementation  possible)  [Ref.  42]. 
This  also  demonstrates  that  as  modules  are  added  the 
system's  coaplexity  is  reduced,  not  linearly,  but  as  some 
function  of  the  sguare. 

2.  Estimation  of  Adapt ive  Maintenance  Workload 

The  estimates  of  the  amount  of  personnel  effort 
needed  will  require  the  combination  of  the  above  coaplexity 
metric  and  the  benefit  of  previous  experience  on  siailiar 
projects.  The  metric  can,  to  a  large  extent,  predict  the 
amount  of  time  required  to  understand  a  program,  a  factor 
that  is  critical  to  the  proper  conduct  of  adaptive  mainte¬ 
nance.  This  effort  should  be  required  each  time  the  system 
is  to  be  enhanced.  The  shortcoming  of  the  model  is  the 
requirement  for  a  prediction  of  the  frequency  of  enhance¬ 
ments  and  their  degree.  The  degree  of  alteration  is  a  defi¬ 
nite  consideration  as  it  will  govern  the  time  and  effort 
required  to  accomplish  the  changes.  Major  alterations  will 
take  greater  time  and  effort  than  will  minor  ones,  but  a 
large  number  of  minor  changes  can  easily  outweigh  one  major 
change  in  effort. 

The  only  present  method  used  to  estimate  the 
frequency  of  alterations  required  is  experience.  The  degree 
of  enhancement  should  be  divided,  at  least  initially,  into 
major  and  minor.  i  major  enhancement  would  consist  of  at 
least  the  replacement  of  an  old  module  of  the  system  or  the 
addition  of  a  new  one.  A  minor  enhancement  would  consist  of 
an  alteration  to  a  module  in  which  either  a  line  of  code  is 
rewritten  or  replaced,  or  the  module  itself  is  rewritten 


with  its  function  regaining  as  it  was  prior  to  the  aodifica- 
tion.  Ontil  farther  data  is  accumulated  on  the  type  of 
enhancements  conducted,  this  initial  distinction  should  be 
used  to  improve  the  estiaation  process. 

Two  aethods  are  suggested  for  the  use  of  the 
complexity  metric.  The  first  would  consist  of  siaply  multi¬ 
plying  the  average  time  of  all  enhanceaents  by  the  ratio  of 
the  coaplexities  for  the  new  systea  to  the  average  coaplexi- 
ties  of  all  the  previous  systeas.  The  preferred  method, 
though,  is  to  use  the  average  tiae  to  conduct  the  enhance¬ 
ment  and  the  average  complexity  thereof  broken  out  by  the 
enhancement  degree.  Each  resulting  average  by  enhanceaent 
degree  should  then  be  aultiplied  by  the  ratio  of  the  new 
system's  complexity  to  th9  average  of  the  previous  system's 
complexity  and  the  frequency  of  enhancements  per  project. 
This  formula  is: 

J“x  (aa  j)  x  H(aaj)  x  (min)  xN(min)  “| 

ill  *  E  X  - - - - -  ♦  — — - - — - —  <7> 

|JB(aver.  for  maj)  B(aver.  for  min)_| 

where, 

AM*  total  adaptive  maintenance  required  in  man-hours, 
x(aaj)  3  the  average  tine  to  add  a  major  enhanceaent, 
x(ain)  *  the  average  tiae  to  complete  a  minor  enhance¬ 
ment, 

E(aver  for  maj)  *  the  average  complexity  of  aajor 
enhanceaents  using  equation  <6>, 

E(aver  for  min)  »  the  average  complexity  of  minor 
enhanceaents  using  equation  <6>, 

H(aaj)  »  the  average  number  of  aajor  enhanceaents, 
N(ain)  ■  the  average  number  of  ainor  enhanceaents,  and 
E  »  the  complexity  of  the  program  using  equation  <6>. 


N(maj)  and  N  (min)  can  be  used  in  tbe  equation  in  two  ways. 
The  first,  as  presented,  is  as  the  frequency  that  enhance¬ 
ments  of  the  two  deqrees  have  occurred  in  the  past.  The 
other  way  could  be  to  use  an  estimated  number  of  enhance- 
■ents,  if  manaqeaent  has  soie  idea  of  special  circumstances 
in  which  these  numbers  will  vary  from  past  events. 

D.  MODEL  AGGREGATION 

The  entire  maintenance  effort  required  for  the  project 
from  tine  the  system  is  accepted  at  the  maintenance  facility 
can  be  calculated  by  adding  the  estimated  corrective  mainte¬ 
nance  workload  to  the  adaptive  maintenance  workload.  This 
yields: 

TM  =  AH  ♦  CM  <8> 

where, 

TM=  total  combined  maintenance  required  in  man-hours. 

This  result  should  yield  an  estimate  of  the  total  mainte¬ 
nance  effort  required  and  needs  to  be  subdivided  into  years 
to  be  more  useful  to  management.  One  method  of  accom¬ 
plishing  this  is  to  divide  the  total  maintenance  effort  by 
the  estimated  number  of  years  remaining  in  the  project. 
This  will  yield  a  straight  line  average  of  maintenance  that 
fails  to  show  any  variations  that  normally  present  them¬ 
selves  later.  Its  advantage  is  that  it  is  extremely  simple. 
Another  method  is  to  reevaluate  the  project  yearly  using  the 
above  formulas  and  actual  experience.  This  nay  prove  infeas¬ 
ible  as  the  estimation  needs  to  be  conducted  well  in  advance 
of  that  year  for  budgeting  purposes. 

The  last  method  for  developing  annual  personnel  require¬ 
ments  is  to  return  to  the  components  of  maintenance.  Horse 
case  corrective  maintenance  can  be  estimated  as  remaining  at 
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least  constant  if  not  decreasing  throughout  the  reaaining 
life  of  the  software.  The  error  rate  will  prove  highly 
dependent  on  the  enhancement  rate.  It  seeas  reasonable  to 
assuae  that,  if  a  large  nun  bet  of  enhanceaents  are  aade,  the 
system's  error  rate  will  increase  correspondingly.  Thus, 
the  noraal  assumption  that  the  error  rate  decreases  as  the 
project  continues  will  not  prove  valid,  if  a  sizeable  number 
of  enhanceaents  are  aade.  Additionally,  if  no  enhanceaents 
are  aade  the  error  detection  rate  will  never  disappear 
entirely  and  will  remain  much  higher  than  expected.  This 
variation  should  be  insulated  against  by  utilizing  an  annual 
detection  rate  where  the  initial  nuaber  of  estiaated  bugs  is 
divided  by  the  estiaated  annual  detection  rate.  The  esti¬ 
aated  annual  detection  rate  can  be  estimated  from  the  bug 
detection  rate  established  during  the  bebugging  test. 
Periodic  retesting  of  the  systea  should  be  conducted  espe¬ 
cially  when  a  aajor  enhance  sent  has  been  added  to  revalidate 
the  error  detection  rate. 

The  adaptive  maintenance  phase,  at  over  seventy  percent 
of  aaintenance  costs,  accounts  for  the  largest  portion  of 
the  software  aaintenance  budget  in  government  activites 
[Hef.  433.  Therefore,  it  is  this  area  that  demands  the 
greatest  efforts  to  account  for  cyclic  activity.  Again,  no 
predictive  ability  for  the  number  of  enhanceaents  by  type 
exists  in  this  model  and  the  only  aethod  is  to  use  data 
obtained  froa  previous  projects  to  deteraine  the  enhanceaent 
rate  at  different  stages  in  the  aaintenance  phase.  These 
estimates,  broken  out  by  year,  could  then  be  added  to  the 
anticipated  corrective  aaintenance  loading  to  obtain  the 
annual  figures  to  be  used  for  planning.  This  aodel  does 
develop  a  prediction  of  the  quantity  of  resources  required 
to  iapleaent  each  enhanceaent  by  type. 


B.  CHAPTEB  SUMHABY 


The  aodel  has  been  developed  considering  the  two 
elements  of  aaintenance  as  defined  here,  corrective  and 
adaptive  aaintenance.  It  has  farther  been  shown  to  yield  an 
estiaation  of  the  total  aanpower  requireaents  for  the 
project  froa  the  tiae  of  assaaption  of  aaintenance  responsi¬ 
bilities.  These  figures  have  been  aanipulated  to  provide 
annual  estiaates  of  aanpower  requireaents.  Halstead's 
effort  aetric  and  Gilb's  bebugging  provide  the  basis  froa 
which  the  aodel  was  developed. 

The  largest  reguireaent  for  this  aodel,  or  any  aodel  for 
that  aatter,  is  to  obtain  data  with  which  the  results  of  the 
aodel  can  be  calibrated  and  tested.  The  reguireaent  exists 
for  the  establishaent  of  a  data  base  on  personnel  expendi¬ 
tures  during  the  aaintenance  cycle,  without  this  data  any 
aodel  developed  cannot  be  tested  fully.  Additionally,  the 
aodels  developed  will  not  be  calibrated  properly  to  allow 
for  their  fullest  utility. 

The  aodel  developed  here  has  been  designed  to  aaintain, 
to  soae  extent,  siaplicity  in  order  to  allow  it  to  be 
eaployed  in  a  working  environaent.  It  has  been  outlined  so 
that  the  reasoning  should  be  evident,  allowing  aanagerial 
personnel  the  capability  to  adjust  it  to  fit  their  situa¬ 
tion.  The  aodel  is  based  on  those  concepts  that  have  appa¬ 
rently  received  favorable  reviews  and  have  been  eaployed  in 
other  siailiar  situations. 
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IT.  COSCLOSIOBS 


As  this  research  has  shown,  it  is  iaportant  to  establish 
early  is  the  life  of  a  software  project  the  desire  to  reduce 
saint enance  costs.  Hith  this  coaaitaent,  the  developaent 
phase  aay  take  longer  and  cost  aore,  but  the  long-tera 
results  will  be  worth  the  extra  effort.  Maintenance  costs 
will  continue  to  consuae  the  largest  portion  of  the 
resources  allocated  to  software  systeas  and  only  through  the 
conscientious  application  of  the  tenets  outlined  in  Chapter 
II  can  this  portion  be  expected  to  be  reduced. 

Host  iaportant  of  these  tenets  is  the  use  of  structured 
design  and  structured  progressing  to  aid  in  the  reduction 
and  identification  of  potential  errors  early  in  the  life  of 
the  project.  This  is  the  tiae  when  they  are  least  expensive 
to  repair.  Reused  code  will  provide  benefits  throughout  the 
entire  life  of  the  project  by  reducing  devlopaent  and 
aaintenance  costs  by  providing  previously  coded  and  tested 
nodules  for  inclusion  in  the  software  being  developed.  The 
use  of  a  high  level  language  will  increase  the 
aaintainabilty  of  the  prograa  by  asking  it  aore 
understandable. 

The  estiaation  of  the  personnel  reguireaents  will  aid 
aanageaent  during  the  budgeting  process.  The  nuaber  of 
unplanned  occurrences,  such  as  exceeding  budget  liaitations 
or  unexpected  levels  of  aaintenance,  will  decrease  because 
of  greater  coaprehension  of  the  aaintenance  phase  and  its 
coaponents. 

This  aodel  is  a  first  atteapt  at  developing  a  systea 
that  will  estiaate  the  personnel  reguireaents  for 
aaintenance.  It  has  been  presented  in  such  a  Banner  as  to 


increase  understanding  of  the  iteas  that  affect  aaintenance 
in  both  favorable  and  unfavorable  vays.  The  reader  is 
encouraged  to  utilize  the  aodel  and  adapt  it  to  his  own  use 
by  applying  it  to  his  own  situation  and  requireaents. 

in  iaportant  itea  to  note  is  that  a  data  base  has  to  be 
established  that  catalogs  those  iteas  concerning  the 
software  that  are  iaportant  to  the  estiaation  and 
understanding  of  the  software  aaintenance  process.  This 
inforaation  should  include  at  least  error  detection  rates, 
correction  tiaes,  nuaber  of  enhanceaents  Bade  as  well  as  the 
estiaated  rates  for  each  of  these  iteas. 
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